Similarly to server instance certificate checking described above, in a secured OPC-UA solution, the OPC client identifies itself to the OPC server using its own instance certificate. The OPC server authenticates the certificate and checks whether the communication with that OPC client is authorized. Typically, the process of checking other party’s instance certificate is achieved through use of certificate trust lists, accessible programmatically and by means of UA Configuration Tool (installed with our product, and with OPC-UA downloads provided by OPC Foundation).
When you are running or developing an OPC-UA client application with OPC Studio, this client application must therefore typically provide its instance certificate to the OPC servers it is connecting to. OPC Studio attempts to make this process easier by automatically selecting parameters for the certificate, and if the certificate does not exist yet, by creating it and storing into the appropriate certificate store on the computer. Depending on your deployment scenario, you may also create the certificate and put it into the certificate store by some other means, and in that case, you would simply let OPC Studio use that certificate.
When the effective endpoint selection policy only allows connection with no message security, the client instance certificate is not used (and not required) when creating the OPC UA session.
The type and location of client instance certificate store can be controlled by properties in EasyUAApplication.ApplicationParameters.ApplicationManifest, such as the InstanceOwnStorePath Property. By default, OPC Studio uses a standard directory-based store defined by OPC Foundation (“MachineDefault”).
The AllowUserInteraction Property of the EasyUAApplication.ApplicationParameters.InstanceCertificateGenerationParameters determines whether the component can interact with the user when checking or creating an application instance certificate. If set to false, no dialogs will be displayed.
Applications based on OPC Studio components will automatically generate the application instance certificate if one is not found, and the AutoGenerateInstanceCertificate Property is true (which is the default setting).
The auto-generation of client instance certificate is skipped when the effective endpoint selection policy only allows connections with no message security.
If you let OPC Studio create the certificate and add it to the store, it should be noted that it is a security-sensitive operation that would typically be allowed only to administrators. OPC Studio will attempt to do this if the certificate is not found, which may be when the application is first started on the computer, but if your application is not running with privileges required for this operation, the certificate will not be added.
In order to allow your application be run under usual privileges, and make its behavior more predictable, it is recommended that you assure the generation of the certificate during the application deployment, when administrative privileges are usually required anyway. One way to do this is call the static method EasyUAClient.Install during the deployment process. For more information, see the “Application Deployment” chapter.
The default validity period of the auto-generated certificate is 60 months (5 years). The default key size of the auto-generated certificates is determined by the OPC UA stack, and is currently 2048 bits.
The auto-generated certificate lifetime, and its key size, can be influenced by parameters in the EasyUAClient.SharedParameters.EngineParameters.InstanceCertificateGenerationParameters Property, which contains an instance of CertificateGenerationParameters Class.
The minimum key size of the generated certificate (in bits) is given by the MinimumKeySize Property. The underlying generation certificate mechanism will choose a key size that is greater or equal to the value of this property. The default value of this property, which is zero, causes the certificate generation mechanism to choose its default key size.
The lifetime of the generated certificate (always expressed in whole moths) is given by a combination of two properties: The MaximumExpirationDate Property and the ValidityPeriodInMonths Property. Whichever property yields a shorter lifetime (in months), wins. By default, the MaximumExpirationDate Property is set to a maximum valid date, and the ValidityPeriodInMonths Property is set to 60 months (5 years).
If you do not like the parameters of the auto-generated certificate, you can also create your own certificate and place it into the appropriate certificate store(s). As long as the certificate has the proper Subject Name, it will be found by OPC Data Client and used.
When using the EasyUAClient.Install method during the deployment process, make sure that the application (certificate) name is the same during deployment, and during the normal application. With automatically generated application name (which is the default), a different name might be generated if you use a separate application for the deployment, or if use you use utilities such as InstallUtil.exe which effectively act as a host for your application. In such situations, always set the application name explicitly, to the same value during the deployment and in normal application executions.
OPC Data Client attempts to re-generate the own instance certificate whenever it is needed and not found. You can therefore enforce re-creation of the instance certificate (e.g. periodically, in order to prevents its expiration) by simply removing it from the appropriate certificate store (e.g. by a script called from Windows Task Scheduler). Note that when the instance certificate is replaced, the other parties (communication peers) will most likely no longer trust the certificate, and the trust will have to be reestablished on their side.
When OPC Studio creates or checks the client instance certificate (in the application certificate store), it also makes sure that the certificate is to be found in the trusted peers certificate store ("UA Applications", normally). If the client instance certificate store is not found there, a copy of it (without the private key) is placed into the trusted peers certificate store automatically.
With this peer auto-trust mechanism, OPC UA servers that use the same trusted peers certificate store can automatically trust the client application(s) created with programs based on OPC Studio.
Whether the auto-generated client instance certificate will be also placed into the trusted peers certificate store can be controlled using the AutoTrustInstanceCertificate Property.
If the ValidateOwnInstanceCertificate Property is true, and the application instance certificate is found in the appropriate certificate store, OPC Studio program validates the certificate. If any checks fails, and instance certificate auto-generation is turned on (which is by default - see above), OPC Studio program creates a new certificate and replaces the certificate in the store.
For OPC compliance, the application instance certificate validation must be turned on.
OPC-UA usually requires that both parties (client and server) mutually identify themselves using application certificates. The certificates are supposed to be unique for each application (instance), and therefore cannot be a constant part of the "toolkit" (such as OPC Studio), and need to be generated. In order to make this process invisible (in common cases) to the developer, OPC Studio
a) determines the parameters of the certificate automatically, using values such as the EXE name or the calling assembly name,
b) attempts to look up the certificate in the certificate store,
c) if not found, it attempts to create it, and save it into the certificate store.
The algorithm described above does not, however, fit well with hosted environments such as IIS, for two reasons:
For usage in such environments, the recommendation is:
On Windows, application certificate can be manually generated using Opc.Ua.CertificateGenerator.exe utility, available (in source code) from the OPC Foundation GitHub. If you have used some older OPC UA software, the utility might be installed on your system, and is typically located at "C:\Program Files (x86)\Common Files\OPC Foundation\UA\v1.0\Bin". If you do not have it on your system, you can download our build of it from our Knowledge Base: Tool Downloads (UA Certificate Generator) . Run the tool with "/?" on the command line to obtain usage instructions. See also Certificate Generator page.
Setting the certificate parameters is done by modifying properties in EasyUAClient.SharedParameters.EngineParameters.ApplicationParameters (EasyUAClient.SharedParameteres is a static property, and you are advised to set the values before creating the first instance of EasyUAClient, in order for it to always have the desired effect for certificate auto-generation). The properties of interest are:
The values should match those used when the certificate was generated, because they (or at least some of them) are used to look up the certificate in the store.
The application URI can be set to a specific value, or (when not set, which is the default), OPC Studio will use the application URI template string to make an application URI. For the template syntax, and more details about how application URI is determined, see OPC UA Application URI Derivation.
You should not use the same certificate for multiple applications. And, you should not use the same certificate even for multiple instances of the same application (such as when you deploy the application on multiple computers). Each instance of the application (typically, this means each application/computer combination, but can be even more granular) should have its own, unique certificate. This is how UA security is meant to work, because there needs to be a way for the server to authenticate each client connection separately and possibly deny the connection to unsecure or compromised clients. Technically, if you violate this and use the same certificate, things will probably work OK on the surface and initially, but it is against the OPC-UA security specs. This is the reason why the certificate is generated anew on the computer - and also the cause of some troubles.
Actually, while generating the certificates manually is possible, it would be probably too complicated to try to assemble the right set of parameters so that the generated certificate is then properly found by the client application. Instead, we suggest that you create a small app (e.g. Windows Forms app, or a console app). In it, you set the 4 parameters in EasyUAClient.SharedParameters to meaningful values, and then call a static method EasyUAClient.Install(). You then run this application with administrator/elevated privileges, and it will create the certificate (verify it with the UA Configuration Tool described above). In your actual client app, set the parameters in precisely the same way before instantiating the EasyUAClient object, and doing so should assure that it will find and use the certificate. Still, your app (which may be a Web app) needs to have read access to the directory of the cert store - you may have to modify the permissions). The additional app you created may become part of your installation procedure.
In advanced scenarios, an OPC UA application may use multiple application instance certificates, with the help of so-called certificate sub-ids. For more information on this subject, see OPC UA Client-Server Application Service.
It is possible to protect the private key of the client instance certificate with a password. The password can be set using the UAClientServerApplicationParameters.InstanceCertificatePrivateKeyPassword Property. The same password setting is used when accessing an existing private key, or when a new certificate is generated (together with its private key).
In addition, the relevant operations on the IEasyUAClientServerApplication interface (see OPC UA Client-Server Application Service) also have an additional argument for the private key password.
You can also password-protect or unprotect the private key of an existing certificate. The corresponding methods (and extension methods) on the IEasyUAClientServerApplication Interface are: ProtectOrUnprotectOwnCertificate, ProtectOwnCertificate, and UnprotectOwnCertificate.
You are responsible for providing and/or persisting the private key password. That is, if you simply protect the certificate with the password, without further actions, the next time the application runs, it will not know what the pasword was. Extra code is needed to make sure the proper password is used each time the application is run. For example, a fixed password might be hard-coded in your program. This approach works, but you need to be aware that the password can be extracted from the program if the attacker gains access to it, and that hard-coding the password also makes it difficult to change it. More sophisticated solutions will e.g. persist the password in some kind of a secure storage area.
If your OPC UA setup includes an OPC UA Global Registration Server (GDS), you might be able to obtain the application instance certificate from the GDS (in the role of Certificate Manager, CM). For more information, see OPC UA Client-Server Application Service (or, less preferrably, OPC UA Certificate Management Client).
Some common problem scenarios include:
Certificate generation works on one computer, does not on other. For example, when you first run your application your development computer, you may use the development Web server built-in in Visual Studio. This one uses different accounts and permissions from IIS, and the certificate creates just fine. On the production computer, IIS is used, and the certificate generation may fail. See further below for related information.
Certificate generation fails under IIS. Most likely this is due to permissions. IIS settings are VERY restrictive (for good reason), and the defaults won't allow the certification generation or storing it into the store.